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DEVELOPING  A  BATTALION  INFORMATION  ARCHITECTURE 


"I  am  convinced  that  leaders  of  this  battalion  are  capable  of  doing  a 
much  better  job  of  managing  resources  than  our  recent  performance 
indicates,"  said  the  battalion  commander,  LTC  Brown.  Others  at  the  weekly 
command  and  staff  meeting  glanced  nervously  at  each  other  wondering  what  their 
new  commander  had  on  his  mind. 

He  continued,  "I'll  bet  each  of  you  has  the  same  problems  I  have  in 
trying  to  get  information  for  what  seem  like  simple  decisions.  I  know  the  data 
is  available  somewhere  in  the  battalion,  but  it  is  usually  not  where  I  want  it 
or  not  in  a  form  useful  to  me.  Our  filing  cabinets  are  overflowing  and  we 
have  literally  mounds  of  papers  filling  our  in-boxes,  but  we  don't  have  a  good 
handle  on  the  information  we  need  for  doing  business.  We  often  waste 
soldiers'  and  leaders'  time  with  duplicative  efforts  chasing  down  the  same 
bits  of  data  for  similar  decisions  when  that  information  would  easily  be 
obtainable  if  we  understood  the  concept  of  a  corporate  data  base.  It  bothers 
me  to  see  company  commanders  and  first  sergeants  either  chasing  information  or 
feeling  tied  to  their  desks  instead  of  using  quality  time  to  train  soldiers." 

The  S3  squirmed  in  his  seat  thinking  of  the  amount  of  company  commander 
time  he  had  consumed  the  previous  week  preparing  the  exercise  OPORD  for  the 
upcoming  brigade  training  exercise.  Had  he  had  better  information  about 
equipment  and  personnel  readiness  of  the  different  companies,  he  could  have 
easily  prepared  the  OPORD  without  requiring  another  meeting. 

At  the  same  time,  the  SA  was  reminded  of  the  scramble  he  and  the  company 
supply  sergeants  had  just  finished  to  reconcile  the  battalion  property  book 
with  handreceipts  for  all  the  vehicles  in  the  battalion.  "If  we  only  had  an 
easy  way  of  crosschecking  the  property  book  and  handreceipts,"  he  thought. 

The  commander  continued,  "Each  of  us  is  a  leader,  but  we  should  also  be 


responsible  managers  or  stewards  of  resources  entrusted  to  us.  There  is  much 
ve  can  learn  from  business  and  well  managed  military  units  that  have 
learned  to  exploit  modern  techniques  and  technology  to  improve  information 
support  to  decision  making.  I  want  this  battalion  to  begin  to  learn  these 
lessons  and  do  a  better  job  of  managing  our  information  resource." 

LTC  Brown  recognized  that  his  battalion  was  suffering  from  information 
problems  common  to  many  tactical  units.  While  the  doctrinal  literature  did  a 
decent  job  of  identifying  information  needs  in  a  tactical  setting,  it 
offered  little  support  in  the  area  of  information  support  to  routine  garrison 
decision  making.  Ideally,  the  wartime  information  system  should  be  the  one  used 
during  peacetime  in  the  garrison  environment.  Realistically,  decisions  were 
similar  in  the  garrison  and  tactical  environments,  but  information  flows  were 
different.  In  garrison,  the  division  and  brigade  commanders  expected  certain 
items  of  information,  such  as  budget  data,  to  be  readily  available  by  the 
battalion  leaders.  It  seemed  to  LTC  Brown  that  too  often  the  division 
staff  had  better  access  to  information  about  the  battalion  than  did  members  of 
the  unit  itself.  A  comprehensive  look  at  the  garrison  information  needs  of 
the  battalion  was  needed. 

LTC  Brown  reflected  that  information  needs  had  been  mentioned  by  the 
division  commander  and  had  been  a  familiar  theme  of  other  commanders.  In  his 
orientation  visit  with  the  division  IG,  this  former  battalion  commander  had 
observed  that  units  with  good  information  systems  tended  to  be  both  well 
managed  and  well  led.  The  IG  and  other  commanders  remarked  that  making 
long  term  fixes  on  the  unit's  information  systems  took  careful  planning  but 
paid  great  dividends. 

Attempts  by  some  to  implement  long  term  improvements  were  frustrated  by 
the  chronic  problems  of  personnel  turbulence,  reorganizations  and  changing 
emphasis  by  higher  headquarters.  New  people  were  always  coming  into  the 


organization  causing  training  on  the  unit  information  system  to  be  a 
continuous  process.  Likewisct  organizational  changes  often  changed  information 
flows.  Frustration  was  also  expressed  with  the  changing  requirements  for 
information  by  higher  headquarters,  although  this  was  seen  as  part  of  the  need 
to  have  a  good  handle  on  the  battalion's  own  internal  information  system. 

On  the  positive  side,  LTC  Brown  was  pleased  to  discover  that  the 
battalion  had  obviously  been  managed  by  objectives  which  were  clearly  stated 
for  leaders  at  all  levels.  Progress  toward  these  objectives  was  usually 
measured  based  on  information  gathered  through  personal  observations  of  the 
more  experienced  leaders.  For  example,  observed  performance  of  platoons  in 
accomplishing  ARTEP  tasks  was  the  key  means  of  assessing  wartime  readiness  and 
identifying  training  deficiencies.  Unfortunately,  junior  leaders  were  less 

able  to  spot  systemic  problems  due  to  their  inexperience.  They  generally 
lacked  an  appreciation  for  the  way  the  rest  of  the  battalion  operated.  An 
effective  means  of  relating  objectives  to  decision  making  information  needs 
was  needed  to  assist  junior  leaders  to  overcome  this  experience  gap. 

The  battalion  commander's  attention  was  brought  back  to  the  meeting  by 
CPT  Sparks,  the  battalion  communications-electronics  staff  officer,  who  said, 
"We  really  are  in  the  stone  age  in  information  technology  compared  to  many 
businesses.  The  only  pieces  of  modern  information  technology  we  have  in  the 
battalion  are  Che  word  processor,  which  runs  almost  24  hours  a  day,  and  a 
reproduction  capability  that  is  usually  broken.  One  first  sergeant  has  become 
so  frustrated  redoing  lists  and  other  routine  correspondence  Chat  he  brought 
his  personal  computer  into  Che  orderly  room.  It  has  virutually  replaced  the 
typewriter  in  that  company.  I  am  sure  Che  first  sergeants  could  quickly 
identify  a  dozen  microcomputer  applications  that  would  significantly  improve 
both  company  and  battalion  administrative  efficiency.  We  have  gone  beyond  the 


need  for  one  word  processor  at  battalion  level.  Each  company  and  staff 
section  could  use  a  microcomputer,  especially  one  linked  into  a  battalion 
system.  It  would  save  us  hours  of  time  and  improve  support  to  the  soldiers." 

"Help  is  already  on  the  way,"  spoke  up  the  S4.  "The  September  1985  issue 
of  Army  magazine  had  an  article  about  the  Army's  tests  of  the  Tactical  Army 
Combat  Service  Support  Computer  System  (TACCS)  for  battalion  and  company  use. 
We  should  find  out  how  this  system  works  to  improve  information  efficiency  in 
the  areas  of  supply,  personnel,  maintenance,  communications  security,  and 
property  accountability  before  we  go  off  half-cocked  and  reinvent  the  wheel." 

"The  point  is,"  exclaimed  CPT  Sparks,  "Soldiers  of  this  battalion  are 
well  aware  of  the  advantages  of  computers  because  many  of  them  already  own 
personal  computers  in  their  homes.  If  businesses  can  improve  productivity  and 
management  effectiveness  by  treating  information  as  a  resource,  we  can 
too.  We  should  prepare  ourselves  to  capitalize  on  the  technology  without 
waiting  for  someone  else  to  fix  the  problems  for  us.  At  least  we  can  identify 
our  own  needs." 

As  the  meeting  ended,  it  had  become  clear  to  LTC  Brown  that 
the  unit  needed  a  simple  but  comprehensive  way  of  portraying  the  battalion's 
overall  information  architecture.  This  architecture  must  be  easy  to 
understand,  oriented  to  the  decision  makers  of  the  battalion,  and  should 
serve  as  a  blueprint  for  how  information  ought  to  flow  throughout  the 
battalion  regardless  of  personalities  or  organizational  changes.  It  should 
orient  on  the  decision  processes  and  information  needed  to  make  these 
decisions,  and  it  should  clearly  depict  how  data  should  be  shared  among  the 
different  decision  processes.  Such  an  "ideal"  information  system  could  also 
be  used  to  evaluate  the  current  system  and  determine  where  fixes  are  needed  to 
improve  support  to  decision  makers. 

The  following  morning,  the  battalion  commander  met  with  the  XO  and  the 


communications-electronics  staff  officer,  CPT  Sparks,  who  he  planned  to 
designate  as  project  officer  for  an  information  needs  study  of  the  battalion. 

"This  installation  has  recently  completed  an  information  needs  study 
using  the  Business  System  Planning  (BSP)  methodology  developed  by 
International  Business  Machines  (IBM)",  the  commander  began.  "It  has  been 
used  'successfully  in  hundreds  of  different  businesses  and  governmental 
organizations  to  accomplish  essentially  what  we  need  to  do  in  this 
battalion.  More  importantly,  the  Director  of  Information  Management  (DOIM)  on 
this  post  is  very  familiar  with  the  methodology  and  is  willing  to  assist  in 
any  way  necessary.  CPT  Sparks,  I  want  you  to  lead  the  study  effort  to  develop 
a  battalion  information  architecture  using  the  BSP  methodology.  Become 
familiar  with  the  methodology  and  brief  us  at  the  next  command  and  staff 
meeting  on  how  you  intend  to  proceed.  This  is  an  important  endeavor  which 
will  require  maximum  cooperation  by  all  decision  makers  within  the  battalion 
and  you  can  count  on  the  XO's  and  my  total  support." 

BEGINNING  THE  PROJECT 

By  the  next  command  and  staff  meeting  CPT  Sparks  had  met  with  the 
installation  DOIM  and  become  familiar  with  the  IBM  published  Information 
Systems  Planning  Guide,  which  had  been  used  in  developing  the 
installation  information  architecture.  He  learned  that  not  only  had  many 
Army  installations  used  this  same  methology,  but  it  had  been  used  by 
Department  of  the  Army  Headquarters  and  several  Major  Army  Commands. 

At  the  meeting,  CPT  Sparks  explained  his  project  and  highlighted  the 
steps  to  be  followed: 

-  Begin  by  gaining  the  commitment  of  leaders  to  the  objective  of  an 
improved  information  system. 

-  Develop  a  thorough  understanding  of  the  organization  by 


identifying  its  objectives,  decision  processes  and  data  classes. 


-  Identify  who  in  the  unit  is  involved  in  the  decision  process. 

-  Develop  an  information  architecture  which  links  decision  processes 
and  information  they  create  or  use. 

-  Identify  information  shortfalls  and  problems. 

-  Determine  needed  information  system  enhancements  and  priorities. 

The  battalion  commander  strongly  endorsed  the  efforts  of  CPI  Sparks  and 

reiterated  the  importance  of  this  project  for  the  entire  battalion.  He 

identified  other  members  of  the  study  team,  which  included  representation  from 

each  staff  section,  a  company  XO  and  a  former  1st  Sergeant.  The  study  team 
was  excused  from  other  duties  for  a  period  of  three  weeks,  provided  with  a 
work  location  and  assigned  a  couple  of  soon-to-PCS  soldiers  with  typing  skills 
to  assist  with  administrative  matters.  Such  an  investment  in  time  and  talent 
was  considered  necessary  if  any  progress  was  to  be  expected. 

While  completely  hypothetical,  what  follows  is  an  account  of  how  the 
study  team  proceeeded  to  develop  a  battalion  information  architecture  using 
the  IBM  Business  System  Planning  methodology. 

GAINING  LEADER  COMMITMENT 

Following  the  BSP  guidelines,  CPT  Sparks  first  ensured  the  commitment  of 
the  leadership  of  the  battalion.  If  the  study  were  to  change  the  way 
information  flows,  it  would  change  the  way  the  battalion  did  business.  It  was 
clear  that  the  study  should  reflect  the  way  the  collective  leadership  of  the 

battalion  saw  the  unit  and  Che  study's  success  depended  upon  their 

participation  in  providing  an  understanding  of  information  required  for 
decisions.  Approval  of  any  final  architecture  would  commit  the  unit  to  a 
certain  direction  in  the  use  of  information  making  it  important  at  the 
beginning  to  minimize  misunderstandings  of  the  leaders  who  would  Chen  have  to 
live  with  it. 

The  personal  involvement  of  the  battalion  commander  was  strong  support  to 


the  project  since  it  not  only  promoted  interest,  but  significantly  increased 
the  likelihood  that  the  resulting  plan  would  have  the  necessary  top-down  focus 
required  to  support  improved  decision  making.  CPT  Sparks  was  a  good  choice  as 
team  leader  since  he  had  access  to  the  leaders  of  the  unit  and  could  correctly 
iterpret  their  inputs.  The  commander  again  emphasized  his  commitment  to  the 
project  by  reiterating  the  need  for  all  leaders  to  support  CPT  Sparks  and  his 
study  effort.  Company  commanders  and  staff  officers,  while  not  enthusiastic 
about  giving  up  key  people  to  man  the  study  team,  were  openly  supportive 
of  the  project  because  it  held  out  hope  for  more  efficient  operations. 

UNDERSTANDING  THE  ORGANIZATION 

CPT  Sparks  and  his  study  team  began  to  view  the  battalion  as  a  set  of 
information  processors  that  create,  process  and  transmit  information  for  the 
purpose  of  making  decisions.  These  decisions  in  turn  create  additional 
information  to  be  processed  and  transmitted.  Understanding  the  battalion 
organization  meant  more  than  examining  a  line  and  block  chart.  It  meant 
determining  what  decision  processes  were  involved  in  creating  or  using  data 
toward  the  accomplishment  of  the  unit's  objectives. 

The  team  began  by  examining  the  battalion's  objectives.  These  could  be 
found  by  looking  at  the  formal  objectives  stated  in  the  unit's  command 
briefing  and  by  studying  the  commander's  Officer  Efficiency  Report  Support 
Form  (DA  FORM  67-8-1).  A  quick  check  of  the  company  commanders',  command 
sergeant  major's  and  executive  officer's  support  forms  confirmed  that  their 
major  performance  objectives  were  subordinate  to  and  supporting  those  of  the 
battalion  commander.  Later,  key  leaders  would  be  asked  to  identify  those 
things  that  absolutely  must  go  right  for  them  to  be  successful  in  their  jobs. 
These  "critical  success  factors"  in  combination  with  the  objectives  of  the 
unit  would  be  useful  in  deciding  the  priority  of  repairs  needed  to  the 
information  system. 
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As  Che  study  team  prepared  to  conduct  interviews  with  Che  leadership  of 
Che  battalion,  Che  most  time  consuming  and  probably  most  important  activity 
for  them  was  the  identification  and  definition  of  decision  processes  and  data 
classes.  These  processes  and  data  classes  would  not  only  form  Che  basis  for 
the  interviews,  but  they  would  be  used  to  develop  the  information 
architecture,  problem  analysis  and  other  follow-on  activities. 

A  process  was  defined  as  groups  of  logically  related  decisions  and 
activities  required  to  manage  the  resources  of  the  unit.  The  battalion  made 
decisions  regarding  the  resources  of  money,  people,  materiel,  real  property, 
time  and  information.  Each  resource  was  examined  through  its  life  cycle  in 
the  battalion  from  requirements  determination  to  acquisition  to  stewardship  to 
retirement  to  determine  what  decisions  were  made  within  the  battalion  that 
required  information  support.  Sixteen  processes  (Figure  1)  were  identified. 

Likewise,  data  classes  were  identified  and  defined.  A  data  class  is  a 
logical  grouping  of  data  related  to  things  of  lasting  interest  to  the 
battalion  and  available  for  decision  making.  Eventually,  some  data  classes 
might  be  broken  into  specific  data  elements  for  purposes  of  automation,  but  for 
now  a  general  description  of  information  needs  would  suffice.  The  data 
classes  were  needed  in  order  to  examine  data  sharing  requirements,  assess 
data  necessary  but  either  unavailable  or  insufficient  for  decisions,  and  to  lay 
the  groundwork  for  fixing  data  integrity  responsibility.  During  the 

identification  and  definition  of  data  classes,  there  should  be  one  and  only 
one  process  identified  as  creating  each  data  class.  The  study  group 
identified  34  data  classes  (Figure  1). 

Definitions  for  the  Processes  are  available  in  Appendix  A.  Data  class 
definitions  are  available  in  Appendix  B. 
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ESS 


1.  MANAGE  MILITARY  PERSONNEL 


2.  COMPLY  WITH  AND  ENFORCE  LEGAL 
REQUIREMENTS 

3.  DEVELOP  AND  IMPLEMENT  A  QUALITY 
OF  LIFE  PROGRAM 

4.  MANAGE  SECURITY  PROGRAMS 

5.  IMPROVE  RESOURCE  MANAGEMENT 


6.  ESTABLISH  COMMAND  CLIMATE  AND 
DIRECTION 

7.  MANAGE  AND  CONVEY  INFORMATION 


8.  SHORT  TO  MID  RANGE  PLANNING 


9.  MANAGE  FORCE  CAPABILITIES 


10.  DETERMINE  TRAINING  REQUIREMENTS 


11.  MANAGE  AND  CONDUCT  TRAINING 


1.  MILITARY  PERSONNEL  STRENGTH 

2.  MILITARY  PERSONNEL  DESCRIPTION 

3.  MILITARY  PERSONNEL  ACTIONS 

4.  LEGAL  REQUIREMENTS 

5.  VIOLATIONS 

6.  QUALITY  OF  LIFE  PROGRAM 

7.  COMMUNITY  SUPPORT 

8.  SECURITY  PROGRAMS 

9.  MANAGEMENT  PROGRAMS 

10.  INSPECTION  RESULTS 

11.  POLICIES  AND  PROCEDURES 


12.  COMMUNICATIONS  SYSTEMS 

13.  ADMINISTRATIVE  SYSTEMS 

14.  WAR  PLANS 

15.  CONTINGENCY  PLANS 

16.  AUTHORIZATIONS  (MTOE/OTHER) 

17.  DEPLOYMENT  PLANS 

18.  TRAINING  PROGRAM 

19.  TRAINING  ASSETS 

20.  EXERCISE  REQUIREMENTS 

21.  TRAINING  EVALUATIONS 


12.  SCHEDULE  RESOURCES 


13.  FORMULATE  AND  MANAGE  THE  BUDGET 


22.  TASKINGS 

23.  COMMITTED  RESOURCES 

24.  TRAINING  SCHEDULE 

25.  BUDGET 

26.  FUNDS  STATUS 


14.  MANAGE  MATERIEL 


27.  MATERIEL  REQUIREMENTS 

28.  MATERIEL  REQUISITION  STATUS 

29.  MATERIEL  DESCRIPTION 

30.  MATERIEL  DISTRIBUTION 


15.  MANAGE  MATERIEL  MAINTENANCE 


16.  MANAGE  REAL  PROPERTY 


31.  MAINTENANCE  REQUIREMENTS 

32.  MAINTENANCE  ASSETS 

33.  MAINTENANCE  STATUS 

34.  FACILITIES 


Battalion  Processes  and 


RELATE  PROCESSES  TO  THE  ORGANIZATION 

Once  the  business  processes  had  been  described,  they  would  be  related  to 
the  battalion's  structure  to  assist  the  study  team  to  further  clarify  their 
understanding  of  the  processes.  The  team  developed  a  process/organization 
matrix  (Figure  2)  to  graphically  show  who  made  decisions  and  who  was 
involved  in  each  of  the  processes.  This  matrix  helped  the  team  decide  who 
should  be  interviewed  and  was  authenticated  by  the  interviewees  as  they 
discussed  their  responsibilities  in  each  process. 

A  quick  review  of  the  process/organization  matrix  shows  several  instances 
of  overlapping  responsibility  and  decision-making  authority  for  such  processes 
as  #1  Managing  military  personnel  or  fill  Scheduling  resources.  In  the  case  of 
military  personnel,  the  battalion  commander  had  delegated  specific  personnel 
assignment  decisions  to  the  CSM,  SI  and  company  commanders,  but  reserved  for 
himself  the  decisions  regarding  officers.  Likewise,  time  was  scheduled  in 
part  by  Che  S3,  XO,  CSM  and  company  commanders  with  major  scheduling  conflicts 
decided  by  Che  battalion  commander.  The  matrix  helped  identify  such  potential 
problem  areas  Co  be  clarified  later  during  Che  interviews. 


ORGANIZATION 


PROCESSES 


Manage  military  personnel 


2.  Comply  with  legal  requirements 


3.  Manage  quality  of  life  program 


A.  Manage  security  programs 


5.  Improve  resource  management 


6.  Develop  command  climate 


7.  Convey  information 


8.  Conduct  planning 


9.  Manage  force  capabilities 


10.  Determine  training  requirements 


11.  Manage/conduct  training 


12.  Schedule  resources 


13.  Formulate/manage  budget 


lA.  Manage  materiel 


15.  Manage  materiel  maintenance 


16.  Manage  real  property 
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Legend:  X  -  Decision  maker 

M  -  Major  involvement 
/  -  Some  involvement 
.  -  No  involvement 


Figure  2.  Process/Organization  Matrix 


DEVELOP  AN  INFORMATION  ARCHITECTURE 

Once  Che  processes  and  data  classes  had  been  identified,  the 
relationships  between  processes  and  data  classes  were  established.  This 
could  either  be  done  in  a  flow  diagram  or,  as  illustrated  in  figure  3,  a 
process/data  class  matrix.  When  completed,  this  matrix  became  Che  essence  of 
Che  information  architecture  or  "ideal'*  information  system  sought  by  Che  unit. 
It  was  used  as  an  important  analytical  Cool  for  verifying  data  class 
identification,  communicating  data  sharing  concepts,  analyzing  data  problems 
and  determining  dependencies  between  eventual  automated  applications. 

The  study  team  first  focused  on  identifying  the  process  that  was  the  best 
source  or  "creator"  of  each  data  class.  A  "best"  source  implies  Chat  the 
identified  process  may  not  necessarily  be  the  "only"  source  of  this  data 

class,  but  Chat  it  is  Che  most  logical  process  for  ensuring  the  availability 

and  integrity  of  the  data  for  use  by  the  rest  of  the  information  system. 
Within  the  matrix,  the  letter  "C"  designated  that  one  and  only  one  process 

identified  as  the  creator  of  the  data  class.  For  example,  process  #10 

"Determine  training  requirements"  is  identified  as  Che  creator  of  data  class 
#18  "Training  program"  as  indicated  by  the  "C"  in  the  matrix  where  the  process 
and  data  class  intersect.  In  a  similar  manner,  each  data  class  is  associated 
with  the  one  process  which  is  Che  best  source  for  ensuring  Che  integrity  of 
Chat  data  class. 

In  a  similar  manner,  Che  team  identified  chose  processes  that  would  also 
I  "use"  a  data  class  with  Che  letter  "U"  in  Che  matrix  where  the  process  and 

data  class  intersect.  Some  data  classes,  such  as  #11  "Policies  and 
procedures",  were  expected  to  be  widely  used  while  others  are  not.  The  usage 
of  data  classes  by  Che  overall  Information  system  would  be  essential  in 
planning  for  data  sharing. 
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PROCESS 


DATA  CLASS 


1  MIL  PER  STRENGTH _ 

2  MIL  PER  DESCRIPTION. 

MIL  PER  ACTIONS _ 


LEGAL  REQUIREMENTS. 
VIOLATIONS _ 


QUALITY  OF  LIFE. 


COMMUNITY  SUPPORT. 
8  SECURITY  PROGRAMS 


9  MANAGEMENT  PROGRAMS. 

10  INSPECTION  RESULTS_ 

11  POLICY/PROCEDURES _ 

12  COMMO  SYSTEMS _ 

13  ADMIN  SYSTEMS _ 

14  WAR  PLANS _ 


15  CONTINGENCIES _ 

16  AUTHORIZATIONS _ 

17  DEPLOYMENT  PLANS. 

18  TRAINING  PROGRAM. 

19  TRAINING  ASSETS_ 

20  EXERCISE  RQMNTS_ 


21  TRAINING  EVALUATION. 

22  TASKINGS _ 


23  COMMITED  RESOURCES. 

24  TRAINING  SCHEDULE_ 

25  BUDGET _ 


26  FUNDS  STATUS _ 

27  MATERIEL  RQMNTS _ 

28  MAT  REQUISITION  STATUS 
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30  MATERIEL  DISTRIBUTION^ 
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Legend:  C  -  Creates  data  (Process  creates  data  class) 
U  -  Uses  data  (Process  uses  data  class) 


Figure  3.  Battalion  Process/Data  Class  Matrix 


The  study  team  now  had  the  basic  tools  with  which  to  assess  how 


information  was  expected  to  be  created  and  used  within  the  battalion.  The 

process  and  data  class  definitions  provided  direction  by  focusing  on 
information  needed  to  support  important  management  decisions  of  the  unit.  The 
process/organization  matrix  clarified  who  within  the  organization  was  involved 
in  each  process.  The  process/data  class  matrix  explained  the  relationship 
between  decision  processes  and  the  information  they  either  created  or  used. 
More  detailed  planning  would  define  in  detail  the  data  elements  comprising 
each  data  class  and  which  processes  or  data  classes  should  be  automated. 

During  the  next  several  days,  the  study  team  verified  or  modified  their 
process  and  data  class  definitions  and  their  entries  in  the  process/data  class 
and  process/organization  matrices  through  in-depth  structured  interviews  with 
key  decision  makers  of  the  battalion.  Throughout  the  interviews,  the  focus 
was  on  information  requirements  to  measure  progress  toward  battalion 
objectives  and  to  make  decisions.  Where  possible,  information  shortfalls  were 
identified.  The  battalion  commander  was  the  final  decision  maker  to  be 
interviewed  and  the  team  was  able  to  report  to  him  that  they  not  only  felt 
they  thoroughly  understood  the  decision  making  information  requirements  of  the 
battalion,  but  that  the  leadership  of  the  unit  was  in  general  agreement  that 
the  information  architecture  they  were  proposing  was  valid. 

IDENTIFY  INFORMATION  SHORTFALLS  AND  PROBLEMS 

The  study  team  realized  that  reaching  agreement  on  the  process/data  class 
and  process/organization  matrices  meant  that  the  battalion  would  then  know 
where  it  was  trying  to  go  with  its  information  system.  What  remained  to  be 
done  was  to  document  how  the  existing  information  system  functioned,  identify 
the  problems  that  needed  fixing,  and  establish  the  priority  for  commiting 
resources  to  these  system  enhancements. 

The  present  system  consisted  of  both  manual  and  automated  means  of 
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I  processing  information.  These  were  best  described  by  linking  them  to  the  data 

I 

j  classes  that  had  been  identified.  It  was  now  necessary  to  interview  the 

actual  information  users  or  creaters  within  the  organization  to  learn  in 
detail  how  information  flowed.  To  this  pointi  the  team  had  focused  on  the 

» 

j  decision  makers  and  felt  they  understood  what  information  was  needed.  The 

,  technicians  who  actually  processed  the  data  would  add  the  needed  insights  into 

\  how  to  improve  the  format,  timeliness,  accuracy  and  availability  of  the 

I  information  from  both  internal  and  external  sources. 

t  During  the  process  of  identifying  current  information  system  support,  a 

rather  lengthy  list  of  problems  was  identified  that  became  candidates  for 
later  enhancement  efforts.  As  an  information  problem  came  to  light,  the  team 
documented  it  in  a  "Problem  statement  and  analysis",  or  single  page 
description  of  the  problem,  its  impact  on  decision  making  and  any  possible 
j  solutions  that  would  improve  the  situation.  These  problem  statements 

were  organized  into  the  following  general  categories: 

-  Objectives.  Information  shortfalls  in  measuring  attainment  of 

j  objectives. 

'  -  Organization.  Structural  characteristics  that  inhibit  information 


flow. 


-  Measurement  and  Control.  System  shortfalls  that  inhibit  access  to 
information  needed  for  day-to-day  control. 

-  Current  system  support.  System  shortfalls  that  are  related  to  the 
effectiveness  of  the  present  architecture. 


DETERMINE  SYSTEM  ENHANCEMENT  PRIORITIES 

This  set  of  problems  would  become  the  basis  to  determine 
priorities.  The  team  sorted  the  problems  by  the  process  which 


architecural 
caused  the 


problem  to  provide  a  direct  relationship  between  the  problems  and  the 
subsystems  of  the  information  architecture  established  to  support  a  given 


process.  This  linkage  between  problems  and  processes  allowed  the  priorities 
to  be  set  in  full  consideration  of  the  relative  importance  of  the  processes. 

Unfortunately t  it  was  too  easy  to  develop  a  lengthy  list  of  desirable 
and  useful  information  system  enhancements.  Many  were  manual  fixes  that 
became  apparent  by  examining  the  process/data  class  matrix  and  data  needs  of 
different  decision  makers.  Other  fixes  were  of  an  automated  nature  and  would 
require  the  expenditure  of  time,  talent  and  money  to  accomplish.  The  problem 
was  not  in  developing  the  list,  but  in  deciding  the  priority  in  which  they 
should  be  attacked. 

The  following  general  criteria  were  found  to  be  useful  in  arriving  at  a 
prioritized  list  of  enhancement  projects: 

-  Impact  on  the  unit'-  mission.  Linking  recommended  system 
improvements  to  the  objectives  and  critical  success  factors  from  the  initial 
interviews  helped  determine  if  the  effort  spent  on  a  particular  system 

fix  would  payoff  with  better  information  support  to  measuring  the  attainment 
of  the  unit's  objectives.  For  example,  the  battalion's  most  important 
objective  was  to  provide  effective  combat  support  (i.e.,  electronic  warfare) 
to  maneuver  brigades  during  training  exercises,  despite  sometimes  severe 
personnel  and  equipment  shortages.  The  commander  and  S3  both  felt  it  was 
I  important  to  this  mission  to  be  able  to  quickly  organize  effective  support 

packages  involving  assets  from  three  different  companies.  Needed  was  an 
I  enhancement  that  would  allow  rapid  identification  of  personnel  and  equipment 

!  readiness  status  for  use  in  managing  ’’shortages”  of  key  mission  assets.  This 

enhancement  clearly  would  improve  process  #9  "Manage  force  capabilities",  and 
would  involve  more  than  one  data  class  since  #1  "Military  personnel  strength", 
I  #30  "Materiel  distribution",  and  #33  "Maintenance  status"  might  all  need  to  be 

improved  to  provide  the  more  responsive  information. 


-  Demand 


Information  problems  identified  by  the  users  of  the 


present  system  gave  a  good  indication  of  demand  for  improvement.  For 
example,  the  reenlistment  NCO  complained  that  he  needed  more  timely  data  on  a 
soldier's  record  of  educational  achievements.  This  enhancement  fell  within 
data  class  #2  "Military  personnel  description"  and  indicated  a  level  of  demand 
for  automating  this  data  class. 

-  Cost  versus  potential  benefits.  At  this  stage,  detailed  costs 
estimates  were  not  possible,  but  some  sense  of  the  magnitude  of  the  effort 
was  needed  to  compare  with  expected  gains  in  information  system  efficiency  or 
effectiveness.  For  example,  nearly  all  decision  makers  believed  that  the  use 
of  electronic  mail  throughout  the  battalion  would  significantly  improve  the 
efficiency  of  the  information  system.  This  obvious  benefit  came  with  a 
substantial  cost  over  the  method  of  hand-carrying  floppy  discs  between  micro¬ 
computers  or  relying  on  meetings,  phone  calls  and  papers.  A  more  detailed 
cost-benefit  analysis  was  necessary  before  making  this  a  high  piority  fix. 

-  The  probability  of  success.  When  many  enhancement  projects 

competed  for  the  same  limited  resources  of  time,  money  and  talent,  it  only 
made  sense  to  give  higher  priority  to  projects  with  a  high  probability  of 
success.  Enhancements  that  were  manual  in  nature  and  well  within  the 
capability  of  the  battalion  became  candidates  for  early  effort.  Projects  that 
required  extensive  outside  assistance,  especially  software  development 
beyond  local  capability,  were  delayed. 

The  study  team  presented  these  prospective  criteria  to  the  battalion 
commander  for  consideration  before  applying  them  to  the  list  of  needed  system 
enhancements.  A  decision  was  made  to  treat  all  four  equally  for  purposes  of 
developing  a  prioritized  "project"  list.  The  team  then  analyzed  each  project 
from  the  perspective  of  each  criterion.  This  was  done  through  a  "Delphi 
Technique"  within  the  study  team  by  assessing  a  relative  weight  to  each 
project  for  each  criterion. 


For  example,  one  of  Che  recommended  enhancements  was  Co  "Make  personal 
computers  available  to  companies."  The  study  team,  which  by  now  represented 
the  most  knowledgable  "experts"  in  Che  battalion  regarding  the  unit's 
information  requirements,  was  polled  using  a  questionnaire  that  had  leaders 
rate  how  well  each  enhancement  met  each  criteria  using  a  scale  of  1  to  10.  In 
this  one  example,  Che  results  were: 

-  Impact  on  unit's  mission  =  4.50.  While  microcomputers  might  help  free 
leaders  to  do  a  better  job  of  training,  the  team  collectively  felt  that  the 
companys'  tactical  missions  would  not  be  affected  by  this  enhancement  and  it 
received  a  relatively  low  score. 

-  Demand  =  8.75.  Throughout  the  study  effort,  this  enhancement  was  often 
mentioned  as  a  significant  improvement  in  the  overall  information  system.  It 
was  a  prerequisite  for  other  enhancements  such  as  "electronic  mail",  and  was 
therefore  assessed  to  have  relatively  high  demand  by  Che  study  team. 

-  Cost  versus  potential  benefits  =  8.50.  The  study  team  was  generally  in 
agreement  Chat  Che  purchase  of  four  microprocessors  for  company  use  was  well 
worth  the  cost,  considering  available  competitive  prices  of  different  systems 
and  the  applications  already  identified  for  their  use. 

-  Probability  of  success  =  5.50.  Success  depended  on  obtaining  funding 
from  sources  outside  Che  battalion  and  there  was  considerable  uncertainty 
among  study  team  members  regarding  availability  of  this  support.  As  a  result, 
the  team  collectively  scored  this  criterion  relatively  low. 

Since  the  battalion  commander's  guidance  was  to  weight  each  criterion 
equally,  Che  four  scores  for  Che  different  criteria  were  simply  added  together 
to  obtain  an  overall  prioritization  score  of  27.25  for  this  project.  In  a 
similar  manner,  Che  team  computed  prioritization  scores  for  all  other 
projects.  Using  these  scores  allowed  Che  team  to  present  a  prioritized 
listing  of  system  enhancement  projects  to  Che  battalion  commander. 


CONCLUSIONS 


In  this  hypothetical  situation,  the  battalion  commander  recognized  the 
need  to  systematically  evaluate  his  unit's  information  system.  Application  of 
the  IBM  Business  System  Planning  methodology  was  found  to  be  very  useful. 
Identifying  and  defining  processes  and  data  classes  compells  the  unit  to 
clarify  decisions  and  supporting  information  needs.  Development  of  a 
process/organization  matrix  provides  the  means  for  clarifying  decision  making 
rsponsibilities  and  provides  a  useful  aid  for  explaining  the  organization  to 
newcomers  or  in  resolving  "turf"  battles.  Development  of  a  process/data  class 
matrix  would  help  any  organization  identify  data  sharing  needs  and  data  base 
integrity  responsibilities.  In  an  overall  sense,  development  of  all  of  these 
tools  would  define  the  unit  information  architecture  and  would  facilitate 
improved  understanding  of  information  requirements,  costs  and  availability. 

With  an  information  architecture  defining  the  "ideal"  information  system, 
the  IBM  methodology  is  a  viable  means  of  evaluating  the  effectiveness  of 
current  information  system  support.  Through  interviews  of  both  decision 
makers  and  information  "technicians",  attention  stays  focused  on  needed 
improvements  in  information  support  to  decisions  to  more  nearly  match  the 
"ideal"  offered  by  the  architecture.  These  shortcomings  can  be  expressed  in 
terms  of  recommended  improvements  that  are  prioritized  according  to  the 
carefully  developed  criteria.  The  actual  implementation  of  specific 
enhancement  projects  could  follow  this  comprehensive  study. 

Use  of  the  IBM  Business  System  Planning  methodology  within  a  battalion 
organization  would  result  in  improved  confidence  that  the  resulting  plan  for 
implementing  information  system  improvements  was  sound  and  viable  regardless 
of  subsequent  organizational  or  leadership  changes. 
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APPENDIX  A.  PROCESS  DEFINITIONS 


1.  Manage  military  personnel.  Decisions  regarding  Che  requisition, 
assignment,  evaluation,  accounting  for,  retention  and  departure  of  assigned 
and  attached  military  personnel,  and  providing  them  with  personnel  service 
support . 

2-.  Comply  with  and  enforce  legal  requirements.  Decisions  and  activities 
required,  prohibited,  or  allowed  by  statutes  and  regulations  to  include 
determining  facts,  identifying  issues,  and  interpretations  Co  ensure  that 
contemplated  actions  are  legally  and  regulatorily  proper  and  correct. 

3.  Develop  and  implement  a  quality  of  life  program.  Decisions  and 
activities  associated  with  providing  a  healthy,  supportive,  friendly,  and 
secure  environment  for  army  families  in  the  unit. 

A.  Manage  security  programs.  Decisions  and  activities  to  establish  and 
comply  with  internal  controls  to  provide  for  document,  personnel  and  physical 
security . 

5.  Improve  resource  management.  Decisions  and  activities  to  enhance 
management  efficiency  and  effectiveness  to  include  evaluations,  inspections, 
measurements,  surveys  and  other  forms  of  gathering,  analyzing,  comparing  and 
improving  management  procedures. 

6.  Establish  command  climate  and  direction.  Decisions  and  activities  to 
provide  direction  for  the  unit  in  establishing  command  philosophy,  ethics, 
values,  goals,  and  public  relations. 

7.  Manage  and  convey  information.  Decisions  and  activities  to 
communicate,  receive,  secure,  categorize,  process,  edit,  store,  retrieve, 
disseminate,  and  dispose  of  information. 

8.  Medium  to  short  range  planning.  Determining  requirements  for  and  use 
of  resources  for  1-A  years  into  the  future  to  include  operational  planning  for 
wartime  and  contingency  events. 
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9.  Manage  force  capabilities.  Decisions  relating  to  the  ability  of  Che 
unit  to  accomplish  current  and  future  missions. 

10.  Determine  training  requirements.  The  analysis  of  missions,  Casks 
and  force  modernization  events  to  determine  training  needs. 

11.  Manage  and  conduct  training.  Decisions  relating  to  the  planning  for 
training  to  be  conducted  by  units  and  individuals  and  the  actual  conduct  and 
evaluation  of  training  events. 

12.  Schedule  resources.  Decisions  and  activities  regarding  Che 
indentification,  assignment,  and  monitoring  of  tasking  requirements  for 
manpower,  materiel,  or  organizations. 

13.  Formulate  and  manage  Che  budget.  Decisions  related  to  the 
development  and  submission  of  a  command  operating  budget,  control  of 
expeditures  throughout  the  budget  year,  and  status  of  funds. 

14.  Manage  materiel.  Decisions  and  activities  related  to  determining 
requirements  for  equipment  and  supplies  and  compliance  with  established 
controls  to  ensure  accountability  and  efficient/effective  utilization. 

15.  Manage  materiel  maintenance.  Decisions  and  activities  associated 
with  establishment  of  and  compliance  with  internal  controls  to  ensure  that 
materiel  is  effectively  and  efficiently  maintained  in  a  mission  capable 
status . 

16.  Manage  real  property.  Decisions  and  activities  related  to  internal 
controls  to  provide  for  the  effective  and  efficient  utilization  of  facilities. 


APPENDIX  B.  DATA  CLASS  DEFINITIONS 


1.  Military  Personnel  Strength.  Information  concerning  the  levels  of 
manpower  required  to  accomplish  current  and  future  missions,  support  current 
and  future  force  structure  documents,  and  fill  other  requirements.  It 
includes  how  many,  when,  where,  skills  needed,  PCS  and  ETS  loss  projections, 
reenlistment  program  and  objectives,  unprogrammed  losses,  and  personnel 
requisitions  and  their  status. 

2.  Military  Personnel  Description.  Information  concerning  individual 
soldiers  to  include  name,  rank,  date  of  rank,  SSN,  date  of  birth,  MOS,  length 
of  service,  marital  status,  dependents,  education,  ASI,  SQI,  secondary  MOS, 
unit  of  assignment,  religion  and  blood  type. 

3.  Military  Personnel  Actions.  Those  activities  and  decisions  associated 
with  the  inprocessing,  assignment,  career  development,  equal  opportunity, 
recognition,  promotions,  evaluation,  records  maintenance,  reassignment, 
separation,  or  retirement  as  related  to  the  individual  soldier. 

4.  Legal  Requirements.  Information  pertaining  to  statutes,  laws,  and 
regulations  governing  the  unit. 

5.  Legal  Violations.  Information  pertaining  to  alleged  offenses  against  laws 
(federal,  state  and  local  statutes  or  ordinances),  UCMJ,  regulations  and 
policies  which  may  or  may  not  result  in  formal  charges  by  military  or  civilian 
authority  against  members  of  the  unit  or  their  dependents.  Interim  and  final 
dispositions  include  dismissal  of  charges,  conviction,  and  appeal  processes 
until  a  case  is  closed  by  military  authority. 

6.  Quality  of  Life  Program.  Information  pertaining  to  the  planned  program 
designed  to  provide  a  healthy,  supportive,  friendly,  secure  and  efficient 
community  for  the  units'  Army  families.  Includes  descriptions  of  services 


available,  survey  results,  shortcomings,  and  status  of  improvement  actions. 

7.  Community  Support.  Information  pertaining  to  programmed  and  scheduled 
activities  of  interest  to  unit  personnel  and  community  events  supported  by 
unit  personnel. 

8.  Security  Programs.  Information  pertaining  to  personnel,  physical,  and 
information  security  programs  of  the  unit. 

9.  Management  Programs.  Information  pertaining  to  all  projects,  policies 
and/or  activities  established  or  designed  to  improve  or  enhance  the  management 
effectiveness  or  efficiency  of  the  unit. 

10.  Inspection  Results.  Information  pertaining  to  the  external  and  internal 
reported  results  of  inspections  and  audits  of  all  phases  of  the  operation  of 
the  unit. 

11.  Policies  and  Procedures.  Information  pertaining  to  guidelines  from 
higher  headquarters  and  within  the  unit  regarding  how  the  unit  will  operate. 

12.  Communication  Systems.  Information  pertaining  to  the  communication 
systems  operating  in  or  in  support  of  the  unit.  Includes  a  description  of  the 
systems,  their  capabilities,  requirements  and  untilization. 

13.  Administrative  Systems.  Information  pertaining  to  the  types  of  automated 
and  manual  systems  associated  with  providing  administrative  and  information 
management  support.  Includes  correspondence  management,  records  and  reports 
management,  meetings  management,  automated  data  processing  and  word  processing 
management,  reproduction  and  distribution  management. 

14.  War  Plans.  Information  pertaining  to  planning  for  the  unit  to  support 
all  tactical  plans  directed  by  higher  headquarters.  Includes  identification 
of  directed  and  implied  tasks,  training,  logistics,  personnel,  intelligence 
and  security  requirements,  and  administrative  data  regarding  planning 
documents. 

15.  Contingency  Plans.  Information  pertaining  to  planning  to  respond  to 
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natural  disasters,  civil  defense  emergency,  protection  of  federal  property, 
civil  disturbances,  terrorist  threats  and  other  unforseen  nontactical  events. 
Includes  training  requirements,  materiel,  personnel  staffing,  and  funding  as 
required. 

16.  Authorizations.  Information  concerning  MACOM  authorized  allowances  in 
personnel  and  equipment  for  the  unit.  Includes  MTOE,  TDA,  CTA,  message,  DA 
publication  and  other  authorization  documents. 

17.  Deployment  Plans.  Information  pertaining  to  planning,  scheduling 
resources,  mission  and  movement  of  units  and  individuals. 

18.  Training  Program.  Information  pertaining  to  the  listing  and  adjustment 
to  internally  determined  training  activities. 

19.  Training  Assets.  Information  on  assets  used  to  conduct  or  facilitate  the 
conduct  of  training.  Includes  training  areas  and  ranges,  conference 
facilities,  training  aids,  school  catalogs,  and  ammunition. 

20.  Exercise  Requirements.  Information  pertaining  to  unit  identification  of 
the  type,  amount,  and  required  delivery  dates  of  materiel  and  personnel 
involved  in  deployment  for  an  exercise. 

21.  Training  Evaluation.  Information  pertaining  to  formal  or  informal 
evaluations  of  the  training  status  of  individuals  and  units. 

22.  Taskings.  Information  pertaining  to  requirements,  both  internal  and 
external,  which  will  require  the  tasking  of  individuals  or  units  for  manpower 
or  materiel. 

23.  Committed  Resources.  Information  pertaining  to  resources  committed  to 
meet  tasking  requirements  for  manpower,  materiel,  or  organizations. 

24.  Training  Schedule.  Information  pertaining  to  the  time  and  place  of 
scheduled  training  of  organizations  within  the  unit. 

25.  Budget.  Information  pertaining  to  the  planned  disbursement  of  operating 
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funds  allocated  for  current  fiscal  year  (approved  operating  budget)  and  funds 
required  that  can  be  allocated  for  the  next  fiscal  year  (command  operating 
budget) . 

26.  Funds  Status.  Information  pertaining  to  the  current  status  fo 
appropriated  and  nonappropriated  funds  available  by  funding  category. 

27.  -Materiel  Requirements.  Information  pertaining  to  needed  materiel  that 
must  be  requested  through  the  supply  system,  locally  purchased,  or  leased. 

28.  Materiel  Requisition  Status.  Information  pertaining  to  expected  delivery 
of  repair  parts  or  materiel. 

29.  Materiel  Description.  Information  pertaining  to  materiel  which 
identifies  its  stock  number  or  manufacturer's  part  number,  physical 
characteristics,  and  capabilities. 

30.  Materiel  Distribution.  Information  pertaining  to  the  internal  decisions 
an  precedence  of  the  flow  of  materiel  to  units  to  include  redistribution. 

31.  Maintenance  Requirements.  Information  pertaining  to  the  established 
precedence  of  maintenance  and  the  scheme  for  accomplishing  the  materiel 
maintenance  program. 

32.  Maintenance  Assets.  Information  pertaining  to  maintenance  assets  on  hand 
and  projected.  Includes  historical  and  current  work  load  capabilities  of 
maintenance  facilities. 

33.  Maintenance  Status.  Information  pertaining  to  identification  of  the 
work,  current  status,  and  expected  completion  date  of  materiel  maintenance 
work  orders. 

34.  Facilities.  Information  about  the  physical  characteristics,  location, 
state  of  repair,  utilization  and  work  order  status  of  buildings,  structures, 
and  real  estate. 
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